home *** CD-ROM | disk | FTP | other *** search
- VBLANK VGA Screen Blanker
- Uncopyrighted by
-
- R. M. Utter, ProLogic
- 9598 Union Street
- Scottsville, New York USA
- 14546
-
- rather late in the 20th century
-
- -------------------------------------------------------------------------------
- In this litigious age, I feel obligated to include the following
-
- Express Disclaimer Of Warranty And Liability.
-
- VBLANK is a VGA screen blanker. It is _not_ a CGA, MCGA, EGA or any-other-GA
- screen blanker. Its only mission is to blank the screen of a VGA monitor after
- 4+ minutes of keyboard inactivity, while occupying as little RAM as possible.
- VBLANK has been in active and unfailing use on my system for many months. Should
- you try it on your system only to have your monitor/video card/CPU/whatever
- smoke or melt--well, I'll feel badly. I most certainly won't be liable. You do,
- after all, have VBLANK's source code, and with it, fair warning of exactly how
- the program works. It works rather well, I think. Having gotten that out of the
- way...
- -------------------------------------------------------------------------------
-
- Herewith, version 1d of VBLANK.EXE, a small, VGA-only, screen blanker TSR. See
- the end of this note for details about the trifling differences between 1d and
- the previous version.
-
- In response to problems reported by other users, this additional information,
- not to mention another program, described below, is included.
-
- VBLANK version 1d blanks and unblanks your VGA monitor via hardware.
- Specifically, it sets or clears bit 5 of the VGA clocking mode register. Earlier
- VBLANK versions used BIOS interrupts to accomplish the same task. But, this
- change eliminates the possibility that VBLANK won't work with DOS/BIOS versions
- before 3.3. (Why anyone would install VGA video on a system incapable of
- supporting it properly is another question...)
-
- VBLANK is a TSR (Terminate and Stay Resident) program. It relies on the
- cooperation of other TSRs which intercept the DOS timer and keyboard interrupts
- to work correctly. A crudely designed TSR loaded together with VBLANK can
- entirely disable VBLANK operation. The rather obvious symptom is that the
- screen never goes blank, no matter how long you wait.
-
- BLANKVGA.EXE is intended to eliminate the possibility that VBLANK won't work on
- your system due to a hardware incompatibility. Simply execute BLANKVGA. If your
- VGA monitor goes blank for a period of about three seconds, then you can be sure
- that VBLANK will work if another TSR doesn't interfere with it. If the screen
- doesn't go blank, then your VGA card isn't totally VGA-compatible, and VBLANK
- won't work.
-
- Next, execute VBLANK from the DOS command line, then sit back and relax. If
- BLANKVGA worked, then you can expect VBLANK to blank the screen about 4.5
- minutes after you press <Enter>.
-
- Assuming that all has gone well so far, feel free to add a line invoking VBLANK
- to your AUTOEXEC.BAT, then reboot. If VBLANK now fails to blank the screen
- after 4.5 minutes of k/b inactivity, then another TSR is interfering with its
- operation. In this case, reorder the lines in AUTOEXEC.BAT which invoke TSRs.
- The best approach, probably, is to make VBLANK the last TSR to execute. If this
- doesn't work, then place VBLANK at the top of the list.
-
- --------------------------------------------------------------------------------
- Version 1d represents only the most minimal improvement over the previous
- version. Two changes were made--
-
- 1] VBLANK's two ISRs now exit via a JMP to the saved interrupt vectors rather
- than by the arcane method (PUSH the vector onto the stack, then RET) used
- previously. Each ISR's processing now takes perhaps a microsecond less than
- it did before.
-
- 2] The modification above made it possible to reduce VBLANK's RAM allocation by
- one paragraph (16 bytes).
-
- 3] I discovered, to my horror, that my choice of INT 8, rather than INT 1CH,
- as the source of the clock interrupt was a poor one. On my system, at least,
- there were occasional instances where the DOS date wasn't updated at
- midnight. While I don't know the root cause of the problem, switching to
- INT 1CH seems to have cured it.
-
- Direct comments and queries to me via netmail at 1:260/226.
-